Fixes A-1212.

Problem

prover_getJobs exposes each EpochSession's state, but EpochSession only ever assigned initialized, awaiting-checkpoints, and the terminal states. The intermediate phases that exist to describe active work were never set, so a session read awaiting-checkpoints continuously while it was actually (a) proving the top tree or (b) publishing to L1. Observed on staging-internal: every startProof session sat in awaiting-checkpoints even with logs showing Starting top-tree prove…. This is a regression vs the old EpochProvingJob, which advanced through distinct phases.

Fix

• Add a new non-terminal awaiting-root state to EpochProvingJobState (the zod schema is derived from the same array, so it updates automatically). Not added to EpochProvingJobTerminalState.
• Set awaiting-root when the top-tree (root) prove begins, via the TopTreeJob beforeProve hook — which fires once the sub-tree (checkpoint block) proofs are ready and the root prove is about to start. toTopTreeHooks() now always wires this transition and layers any test-provided hooks on top (previously it returned undefined when no test hooks were set).
• Set publishing-proof at the top of submitProof(), before the L1 submit.

Both transitions are guarded by isTerminal() so a concurrent cancel() still wins (the post-submit isTerminal() check relies on this).

Phase progression is now: initialized → awaiting-checkpoints → awaiting-root → publishing-proof → terminal.

Tests

• epoch-session.test.ts: new "state reporting" test asserts getState() is awaiting-root during the prove and publishing-proof during the submit, then completed. Existing hook-ordering test (before/prove/after) still holds.
• prover-node.test.ts: the JSON-RPC schema round-trip mock now includes an awaiting-root job.

Targets the v5 line — the EpochSession/TopTreeJob/awaiting-checkpoints code (post-#23552) exists only on merge-train/spartan-v5.